It is increasingly common for application programs to store their data in databases. For example, it is common for enterprise-level project scheduling applications like the MICROSOFT PROJECT project scheduling application to do so.
Where an application requires frequent access to data stored in a database, that database is typically optimized for data access transactions. A database optimized in this way is referred to herein as a “transactional database.” Where such an application performs rigorous reporting on its data, it is often true that such reporting is not optimally supported by the application's transactional database. In such cases, it is common for the application to cause the data in its transactional database to be replicated to a database optimized for reporting, referred to herein as a “reporting database.”
This replication relies on a correspondence between the contents of the transactional database and the reporting database. In general, the contents of these two databases are made to correspond by developing corresponding definitions of the contents of the two databases. These definitions are referred to herein as “schemas.” Such schemas typically define the set of fields contained by each of the two databases, and therefore the fields that can be stored and reported on by the application. It is typical for these corresponding schemas to be defined by the application's developer, before the application is shipped to customers.
Despite the best efforts of application developers to (1) anticipate the different kinds of data that customers will want to store and report on with an application and (2) accommodate these kinds of data in the corresponding schemas shipped with the application, it is common for customers to discover a need to store and report on data that is not accommodated in the corresponding schemas shipped with the application. Unfortunately, in the absence of appropriate fields for such data in the shipped schemas, it is often difficult or impossible for a customer to cause the application to store and report on this additional data.
For some applications, it may be possible for the customer to modify both schemas to include customer-defined fields. This approach has a number of disadvantages: First, modifying these schemas often requires a high level of technical proficiency. Second, such modifications may necessitate corresponding modifications to the code of the application, such as (1) modifying code to cause the application to properly store the additional data in the customer-defined fields in the transactional database; (2) modifying code to cause the data in the customer-defined fields in the transactional database to be properly replicated in the reporting database; and (3) modifying code and/or report definitions to cause the data in the customer-defined fields in the reporting database to be properly included in reports produced from the reporting database. Where such modifications are possible, they typically also require a high level of technical proficiency.
In some applications, a few “extra” fields are also included in shipped schemas. To use these extra fields, users must typically manually map the customer-defined fields into the extra fields on the transactional side and manually map the customer-defined fields out of the extra fields on the reporting side. Such manual mapping can make the application much more difficult to use, on an ongoing basis. Also, such extra fields can quickly be exhausted by a customer that wishes to store a number of different kinds of additional data.
In some applications, the delay between data creation in the transactional database and its replication to the reporting database can cause problems. In some cases, an application user can see their data in one part of the system but not in the other due to latency inherent in many approaches to data transfer.
In view of the disadvantages discussed above, a more effective approach to enabling customers of an application to cause the application to store, replicate, and report on additional data would have significant utility.